Building a Red Hat OpenShift Environment on IBM Z by IBM Redbooks

Author:IBM Redbooks
Language: eng
Format: mobi, epub
Published: 2022-08-12T14:59:44.495000+00:00

2.5.1 High availability considerations

Figure 2-12 shows an example of a highly available Red Hat OpenShift Container Platform deployment.

Figure 2-12 Red Hat OpenShift Container Platform cluster HA

For HA, the entities that ensure that the environment is operational can be in a single hardware machine, in different LPARs (as shown in Figure 2-12), or they can be spread across two or more (ideally three) hardware machines.

The three machines amount is chosen for redundancy because of the HA definitions for a quorum. The layers for HA are the same and independent of the numbers of hardware machines, only the rate at which the guarantee for a highly available infrastructure increases with the number of physical machines and sites.

Storage high availability

For storage HA, plan the HA for the hypervisor storage first, where the hypervisor runs and its guests that represent the Red Hat OpenShift Container Platform Nodes. For the storage HA, plan for a solution with storage replication for the Hypervisor storage.

The storage that is used for container workloads can be replicated if local attached storage is used, or it can use software-defined replication. Especially with Spectrum Scale CNSA, you can use a stretched cluster across Metro sites, which is managed by the software-defined storage components in the IBM Spectrum Scale storage servers.

IBM Z and IBM LinuxONE

The hardware and LPAR virtualization of the IBM Z and IBM LinuxONE platform offers characteristics that make them a perfect match for HA (for example, redundancy in the machine by way of hardware design) and highest isolation in an LPAR. Therefore, many installations rely on the characteristic of decades of Meantime Before Failure (MTBF) of IBM Z hardware.

Planning network topology

The network topology can be planned to use multiple network cards and cross configure them to avoid a single point of failure in a card. With bonding, you can solve two challenges: one regarding HA, and the other the enlargement of bandwidth by bonding multiple cards by using Link Aggregation Control Protocol (LACP) or the BOND device in KVM.

Virtualization layer

The hypervisor in the virtualization layer is the last layer bottom-up that you, as a user, need to manage for HA. You can plan to use the z/VM Single System Image feature to build a cluster with up to four z/VM nodes that can be managed from every node. In doing so, a total collapse of the virtualization layer is avoided in an Red Hat OpenShift Container Platform cluster.

High availability nodes in the Red Hat OpenShift Container Platform

The nodes in a Red Hat OpenShift Container Platform environment on IBM Z and IBM LinuxONE are virtual guests that can run in a single LPAR that is under the control of z/VM or Red Hat Enterprise Linux KVM or can run in multiple LPARs. If running a Red Hat OpenShift Container Platform cluster in multiple LPARs, these LPARs can spread across multiple physical machines to reach the highest availability.

As described in this chapter, you can have different types of cluster nodes, such as Control Planes, Compute nodes, and Infrastructure nodes. If one of the nodes fails, Red Hat OpenShift Container Platform cannot automatically restart the node.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.